home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 746 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.0 KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 11 Jul 94  12:58:18
  3. Message-Id: <UUCP.773956892@mettav>
  4. Subject: Digest
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Ken:
  9.  > Busy looping?  What do you call a "do { } while" ???  THAT'S a busy loop
  10.  > if I ever SAW one!
  11.  
  12. Depends what's in the do{}while. Put an event library aes call in it, or
  13. Pause() or Fselect() mint calls in it, and it's not busy waiting.
  14.  
  15.  > I don't quite understand what you mean by saying "low cost".  It's just
  16.  > about four lines of code that is easy to do.  It takes almost no time,
  17.  > because, it checks the object under the mouse.  Here's something that does
  18.  > almost EXACTLY the same thing as rectangle events:
  19.  
  20. Your code only works if the event loop includes a timer event of very small
  21. duration. In which case it slows it down by having this code running regularly.
  22. Fine in a single-tasking system, but it will slow down background tasks.
  23.  
  24.  > The ONLY way you can find out which object is under the mouse is by using
  25.  > objc_find.  There is absolutely no other way to get rectangles under the
  26.  > mouse without having to SAVE the physical dimensions of the rectangles,
  27.  > storing those in an array, and checking the array every time the mouse
  28.  > moves.  That's slower, and I think that's what SOME of you are trying to
  29.  > get at.  This is the FASTEST idea I can think of off the top of my head.
  30.  > Bench- marking may prove faster.
  31.  
  32. No, what you do is you use objc_find to find the rectangle you need to watch
  33. and use mouse rectangle events to watch it.
  34.  
  35.  >> For broadcast messages, you have a point, but collecting non-broadcast
  36.  >> message types is of no relevance.  How many new broadcast message types
  37.  >> currently exist?  0?
  38.  >
  39.  > It's nice to follow some standards.  If you want to code for non-broadcast,
  40.  > that's your choice.  Most of us like to follow a list so they can find
  41.  > out if they can create WM or WF messages as they wish, without clashing
  42.  > with other messages.
  43.  
  44. Why would you want to make a new broadcast message? And I can't think of any
  45. reason for a new wind_set/get mode.
  46.  
  47. [Geneva]
  48.  > Also if I remember correctly, anything allocated by applications 2 and 3
  49.  > actually belong to *application 1*. This means Mallocs, file handles,
  50.  > etc. Nasty.
  51.  
  52. Yes because it is using the existing gemdos kernel which doesn't support
  53. multitasking. MagiC and MultiTOS replace the kernel as well as the aes.
  54.  
  55.  > I would imagine the reason for all this silliness is that Geneva does not
  56.  > really replace AES, but simply hooks into it. If it actually replaced the
  57.  > AES, I doubt any sane person would implement the replacement AES like
  58.  > Geneva does :-)
  59.  
  60. it really does replace the aes. It doesn't, however replace the kernel.
  61.  
  62. Since it is cooperative multitasking how can you say it gives one application
  63. 25% or 50% of the CPU time anyway?
  64.  
  65. Annius:
  66.  > Experience shows that users hate to have to choose between different
  67.  >         (or has shown to me)
  68.  > negative alternatives such as 'abort',  'cancel', 'abandon' etc.
  69.  
  70. Like in DOS where you have a choice of abort and fail you mean? :)
  71.  
  72.  
  73.  
  74.